Presto and Trino's native SHA256/SHA512 take and return VARBINARY, but the parser mapped them to exp.SHA2, the string-to-hex-string expression that MySQL and Spark use. The codebase already models this split with exp.MD5 and exp.MD5Digest, and the presto parser maps native MD5 to MD5Digest one line above the SHA mappings, so this looked like an oversight rather than a decision.

Two changes, both mirroring the MD5 precedent:

• The parser now maps native SHA256/SHA512 to exp.SHA2Digest. Digests survive a round trip and transpile to other digest functions: Trino SHA256(x) becomes UNHEX(SHA256(x)) in DuckDB and stays SHA256(x) in BigQuery, instead of silently turning into a hex-string function.
• The generator renders exp.SHA2 the way md5_sql renders exp.MD5: LOWER(TO_HEX(SHA256(TO_UTF8(x)))), with the UTF8 encode applied when the argument is typed as text. Spark's SHA2(x, 256) now produces the same value on Trino that it produces on Spark. SHA224/SHA384 raise the usual unsupported warning since Presto has no equivalents.

Updated the bigquery and exasol expectations that encoded the old equivalence. Exasol's HASH_SHA256 returns a hex string, so LOWER(TO_HEX(SHA256(x))) is the value-preserving translation there; its presto/trino read entries asserted that a digest function and a hex-string function were the same thing, which is the bug this fixes, so those two entries are removed.

Found while chasing a surrogate key mismatch in SQLMesh on Trino (SQLMesh/sqlmesh#5871): MD5-based keys transpile correctly, SHA256-based keys silently change value.

One adjacent inconsistency deliberately left alone: the bigquery parser maps SHA256 to SHA2Digest but SHA512 to SHA2, while BigQuery returns BYTES for both. Happy to follow up separately if that is wanted.